Improve handling of arrays in @defer and @stream payloads
#12923
Conversation
🦋 Changeset detectedLatest commit: c496039 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
✅ Docs preview has no changesThe preview was not built because there were no changes. Build ID: 65998f1ed1f52cf86e6a07cb |
commit: |
| @@ -0,0 +1,5 @@ | |||
| --- | |||
| "@apollo/client": minor | |||
There was a problem hiding this comment.
I'm marking this as a minor change. While it does fix the array merging behavior, it's a big enough difference to warrant a minor.
| expect(outgoingRequestSpy).toHaveBeenCalledTimes(2); | ||
| }); | ||
|
|
||
| it.each([["cache-first"], ["no-cache"]] as const)( |
There was a problem hiding this comment.
These were added from #11374 (with some tweaks)
| expect(outgoingRequestSpy).toHaveBeenCalledTimes(2); | ||
| }); | ||
|
|
||
| it.each([["cache-first"], ["no-cache"]] as const)( |
There was a problem hiding this comment.
Added from #11374 (with some tweaks)
| Query: { | ||
| fields: { | ||
| friendList: { | ||
| merge: (existing = [], incoming, { field }) => { |
There was a problem hiding this comment.
Should we consider exposing a utility function or helper of some kind to do this kind of thing? At the very least, we probably want to put something in our docs along with @stream that describes how to do this in your own code. This demonstrates that you can maintain the original cached items when using stream instead of default overwriting the array.
| friendList: [ | ||
| { name: "Luke", id: "1" }, | ||
| { name: "Han", id: "2" }, | ||
| { name: "Leia Cached", id: "3" }, |
There was a problem hiding this comment.
This behavior will now rely on a merge function to keep the cached item if the user wishes.
| Query: { | ||
| fields: { | ||
| friendList: { | ||
| merge: (_, incoming) => incoming, |
There was a problem hiding this comment.
I added this here to silence the warning about data loss, but I think this might happen a lot with @stream since fetches against a @stream field will naturally return a shorter list than already-cached lists since the list is streamed in over time.
Should we consider muting the warning for @stream fields like we do for @defer? Or should we recommend adding these type policies to explicitly opt into the @stream behavior?
| export class DeepMerger<TContextArgs extends any[] = any[]> { | ||
| constructor( | ||
| private reconciler: ReconcilerFunction<TContextArgs> = defaultReconciler as any as ReconcilerFunction<TContextArgs> | ||
| private reconciler: ReconcilerFunction<TContextArgs> = defaultReconciler as any as ReconcilerFunction<TContextArgs>, |
There was a problem hiding this comment.
Since this is an internal class, I know we are free to update the API so with that in mind... should reconciler be moved to options instead? Its a bit awkward in places where we need arrayMerge but not reconciler since you have to pass undefined as the first argument.
Thoughts on changing it so we can do:
new DeepMerger({ arrayMerge: 'truncate' });?
jerelmiller
force-pushed
the
jerel/stream-support
branch
from
d071a61 to
096db02
Compare
jerelmiller
force-pushed
the
jerel/array-merge-strategy
branch
from
2a2fbc5 to
9b9d8aa
Compare
jerelmiller
force-pushed
the
jerel/stream-support
branch
from
096db02 to
b05df03
Compare
jerelmiller
force-pushed
the
jerel/array-merge-strategy
branch
2 times, most recently
from
b41de5f to
c496039
Compare
1 participant
Fixes #12660
Fixes #11704
Fixes issues where arrays returned in
@deferpayloads would maintain cached items when the defer array was shorter than the cached array. This change also affects@streamarrays so that when a@streamchunk is processed, it truncates the array to the length of the stream payload. This ensures the length of the final result equals the length of the server array, much like it would if a plainrefetchwere issued.